15 Eylül 2025Türkçe

Python'ın Soyut Temel Sınıflarının (ABC'ler) gücünü keşfedin. Protokol tabanlı yapısal tipleme ile resmi arayüz tasarımı arasındaki kritik farkı öğrenin.

Python Soyut Temel Sınıfları: Protokol Uygulamasına Karşı Arayüz Tasarımında Uzmanlaşmak

\n\n

Yazılım geliştirme dünyasında, sağlam, sürdürülebilir ve ölçeklenebilir uygulamalar oluşturmak nihai hedeftir. Projeler birkaç betikten uluslararası ekipler tarafından yönetilen karmaşık sistemlere dönüştükçe, net yapı ve öngörülebilir sözleşmelere duyulan ihtiyaç hayati önem kazanır. Farklı bileşenlerin, muhtemelen farklı zaman dilimlerinde farklı geliştiriciler tarafından yazılmış olsalar bile, sorunsuz ve güvenilir bir şekilde etkileşim kurmasını nasıl sağlarız? Cevap soyutlama ilkesinde yatıyor.

\n\n

Python, dinamik yapısıyla, soyutlama için ünlü bir felsefeye sahiptir: "ördek tipleme". Bir nesne bir ördek gibi yürüyorsa ve bir ördek gibi vakvaklıyorsa, ona bir ördek gibi davranırız. Bu esneklik, Python'ın en büyük güçlerinden biridir, hızlı geliştirmeyi ve temiz, okunabilir kodu teşvik eder. Ancak, büyük ölçekli uygulamalarda, yalnızca örtük anlaşmalara güvenmek, ince hatalara ve bakım sorunlarına yol açabilir. Bir "ördek" beklenmedik bir şekilde uçamazsa ne olur? İşte bu noktada Python'ın Soyut Temel Sınıfları (ABC'ler) devreye girerek, Python'ın dinamik ruhundan ödün vermeden resmi sözleşmeler oluşturmak için güçlü bir mekanizma sunar.

\n\n

Ancak burada kritik ve genellikle yanlış anlaşılan bir ayrım yatıyor. Python'daki ABC'ler her duruma uyan tek bir araç değildir. Yazılım tasarımının iki farklı, güçlü felsefesine hizmet ederler: kalıtım gerektiren açık, resmi arayüzler oluşturmak ve yetenekleri kontrol eden esnek protokoller tanımlamak. Bu iki yaklaşım arasındaki farkı – arayüz tasarımı ve protokol uygulaması – anlamak, Python'da nesne yönelimli tasarımın tüm potansiyelini açığa çıkarmanın ve hem esnek hem de güvenli kod yazmanın anahtarıdır. Bu kılavuz, her iki felsefeyi de keşfedecek, küresel yazılım projelerinizde her bir yaklaşımı ne zaman kullanacağınıza dair pratik örnekler ve net rehberlik sağlayacaktır.

\n\n

Biçimlendirme hakkında bir not: Belirli biçimlendirme kısıtlamalarına uymak için, bu makaledeki kod örnekleri kalın ve italik stiller kullanılarak standart metin etiketleri içinde sunulmuştur. En iyi okunabilirlik için bunları düzenleyicinize kopyalamanızı öneririz.

\n\n

Temel: Soyut Temel Sınıflar Tam Olarak Nedir?

\n\n

İki tasarım felsefesine dalmadan önce sağlam bir temel oluşturalım. Soyut Temel Sınıf nedir? Özünde, bir ABC diğer sınıflar için bir şablondur. Uyumlu herhangi bir alt sınıfın uygulaması gereken bir dizi yöntem ve özellik tanımlar. Bu, "Bu ailenin bir parçası olduğunu iddia eden herhangi bir sınıf, bu belirli yeteneklere sahip olmalıdır" demenin bir yoludur.

\n\n

Python'ın yerleşik `abc` modülü, ABC'ler oluşturmak için araçlar sağlar. İki ana bileşen şunlardır:

`ABC`: Bir ABC oluşturmak için meta sınıf olarak kullanılan bir yardımcı sınıf. Modern Python'da (3.4+), doğrudan `abc.ABC`'den kalıtım alabilirsiniz.
`@abstractmethod`: Yöntemleri soyut olarak işaretlemek için kullanılan bir dekoratör. ABC'nin herhangi bir alt sınıfı bu yöntemleri uygulamalıdır.

\n\n

ABC'leri yöneten iki temel kural vardır:

Uygulanmamış soyut yöntemleri olan bir ABC'nin örneğini oluşturamazsınız. Bu bir şablon, bitmiş bir ürün değildir.
Herhangi bir somut alt sınıf, tüm kalıtsal soyut yöntemleri uygulamalıdır. Bunu yapmazsa, o da soyut bir sınıf haline gelir ve onun bir örneğini oluşturamazsınız.

\n\n

Bunu klasik bir örnekle görelim: medya dosyalarını işlemek için bir sistem.

\n\n

Örnek: Basit Bir MediaFile ABC'si

\n\n

Çeşitli medya türlerini işlemesi gereken bir uygulama geliştirdiğimizi hayal edin. Her medya dosyasının, formatı ne olursa olsun, oynatılabilir olması ve bazı meta verilere sahip olması gerektiğini biliyoruz. Bu sözleşmeyi bir ABC ile tanımlayabiliriz.

\n\n

import abc

class MediaFile(abc.ABC):\n
    def __init__(self, filepath: str):\n
        self.filepath = filepath\n
        print(f"Base init for {self.filepath}")\n\n
    @abc.abstractmethod\n
    def play(self) -> None:\n
        """Medya dosyasını oynatır."""\n
        raise NotImplementedError\n\n
    @abc.abstractmethod\n
    def get_metadata(self) -> dict:\n
        """Medya meta verilerinin bir sözlüğünü döndürür."""\n
        raise NotImplementedError\n

\n\n

Eğer doğrudan `MediaFile` sınıfından bir örnek oluşturmaya çalışırsak, Python bizi durduracaktır:

\n\n

# Bu bir TypeError hatası verecektir\n
# media = MediaFile("path/to/somefile.txt")\n
# TypeError: Can't instantiate abstract class MediaFile with abstract methods get_metadata, play\n

\n\n

Bu şablonu kullanmak için, `play()` ve `get_metadata()` için uygulamalar sağlayan somut alt sınıflar oluşturmalıyız.

\n\n

class AudioFile(MediaFile):\n
    def play(self) -> None:\n
        print(f"Playing audio from {self.filepath}...")\n\n
    def get_metadata(self) -> dict:\n
        return {"codec": "mp3", "duration_seconds": 180}\n\n
class VideoFile(MediaFile):\n
    def play(self) -> None:\n
        print(f"Playing video from {self.filepath}...")\n\n
    def get_metadata(self) -> dict:\n
        return {"codec": "h264", "resolution": "1920x1080"}\n

\n\n

Şimdi, `AudioFile` ve `VideoFile` örnekleri oluşturabiliriz çünkü `MediaFile` tarafından tanımlanan sözleşmeyi yerine getiriyorlar. Bu, ABC'lerin temel mekanizmasıdır. Ancak asıl güç, bu mekanizmayı *nasıl* kullandığımızdan gelir.

\n\n

İlk Felsefe: Biçimsel Arayüz Tasarımı Olarak ABC'ler (Nominal Tipleme)

\n\n

ABC'leri kullanmanın ilk ve en geleneksel yolu biçimsel arayüz tasarımı içindir. Bu yaklaşım, Java, C++ veya C# gibi dillerden gelen geliştiricilerin aşina olduğu bir kavram olan nominal tipleme üzerine kuruludur. Nominal bir sistemde, bir türün uyumluluğu adı ve açık bildirimiyle belirlenir. Bağlamımızda, bir sınıf bir `MediaFile` olarak ancak açıkça `MediaFile` ABC'sinden kalıtım alırsa kabul edilir.

\n\n

Bunu profesyonel bir sertifika gibi düşünün. Sertifikalı bir proje yöneticisi olmak için sadece öyle davranmanız yetmez; çalışmalı, belirli bir sınavı geçmeli ve niteliğinizi açıkça belirten resmi bir sertifika almalısınız. Sertifikanızın adı ve soyu önemlidir.

\n\n

Bu modelde, ABC tartışılmaz bir sözleşme görevi görür. Ondan kalıtım alarak, bir sınıf sistemin geri kalanına gerekli işlevselliği sağlayacağına dair resmi bir söz verir.

\n\n

Örnek: Bir Veri Dışa Aktarıcı Çerçevesi

\n\n

Verileri çeşitli formatlara dışa aktarmasına olanak tanıyan bir çerçeve oluşturduğumuzu hayal edin. Her dışa aktarıcı eklentisinin katı bir yapıya uymasını sağlamak istiyoruz. Bir `DataExporter` arayüzü tanımlayabiliriz.

\n\n

import abc\n
from datetime import datetime\n\n
class DataExporter(abc.ABC):\n
    """Veri dışa aktarma sınıfları için resmi bir arayüz."""\n\n
    @abc.abstractmethod\n
    def export(self, data: list[dict]) -> str:\n
        """Veriyi dışa aktarır ve bir durum mesajı döndürür."""\n
        pass\n\n
    def get_timestamp(self) -> str:\n
        """Tüm alt sınıflar tarafından paylaşılan somut bir yardımcı metot."""\n
        return datetime.utcnow().isoformat()\n\n
class CSVExporter(DataExporter):\n
    def export(self, data: list[dict]) -> str:\n
        filename = f"export_{self.get_timestamp()}.csv"\n
        print(f"Exporting {len(data)} rows to {filename}")\n
        # ... gerçek CSV yazma mantığı ...\n
        return f"Successfully exported to {filename}"\n\n
class JSONExporter(DataExporter):\n
    def export(self, data: list[dict]) -> str:\n
        filename = f"export_{self.get_timestamp()}.json"\n
        print(f"Exporting {len(data)} records to {filename}")\n
        # ... gerçek JSON yazma mantığı ...\n
        return f"Successfully exported to {filename}"\n

\n\n

Burada, `CSVExporter` ve `JSONExporter` açıkça ve doğrulanabilir bir şekilde `DataExporter`'dır. Uygulamamızın temel mantığı bu sözleşmeye güvenle dayanabilir:

\n\n

def run_export_process(exporter: DataExporter, data_to_export: list[dict]):\n
    print("--- Starting export process ---")\n
    if not isinstance(exporter, DataExporter):\n
        raise TypeError("Exporter must be a valid DataExporter implementation.")\n
    status = exporter.export(data_to_export)\n
    print(f"Process finished with status: {status}")\n\n
# Kullanım\n
data = [{"id": 1, "name": "Alice"}, {"id": 2, "name": "Bob"}]\n
run_export_process(CSVExporter(), data)\n
run_export_process(JSONExporter(), data)\n

\n\n

ABC'nin ayrıca, tüm çocuklarına paylaşılan işlevsellik sunan somut bir yöntem olan `get_timestamp()` sağladığına dikkat edin. Bu, arayüz tabanlı tasarımda yaygın ve güçlü bir desendir.

\n\n

Resmi Arayüz Yaklaşımının Artıları ve Eksileri

\n\n

Artıları:

Belirsiz ve Açık: Sözleşme son derece nettir. Bir geliştirici `class CSVExporter(DataExporter):` kalıtım satırını görebilir ve sınıfın rolünü ve yeteneklerini anında anlayabilir.
Araç Dostu: IDE'ler, linter'lar ve statik analiz araçları sözleşmeyi kolayca doğrulayabilir, mükemmel otomatik tamamlama ve hata kontrolü sağlayabilir.
Paylaşılan İşlevsellik: ABC'ler somut yöntemler sağlayabilir, gerçek bir temel sınıf görevi görebilir ve kod tekrarını azaltabilir.
Aşinalık: Bu desen, diğer nesne yönelimli dillerin büyük çoğunluğundan gelen geliştiriciler için anında tanınabilir.

\n\n

Eksileri:

Sıkı Bağlanma: Somut sınıf artık doğrudan ABC'ye bağlıdır. ABC taşınması veya değiştirilmesi gerekirse, tüm alt sınıflar etkilenir.
Katılık: Katı bir hiyerarşik ilişkiyi zorlar. Bir sınıf mantıksal olarak bir dışa aktarıcı olarak işlev görebilirken, zaten farklı, temel bir temel sınıftan kalıtım alıyorsa ne olur? Python'ın çoklu kalıtımı bunu çözebilir, ancak kendi karmaşıklıklarını (Elmas Problemi gibi) da beraberinde getirebilir.
İnvaziv: Üçüncü taraf kodu uyarlamak için kullanılamaz. Eğer bir `export()` metodu sağlayan bir kütüphane kullanıyorsanız, onu alt sınıflara ayırmadan (ki bu mümkün veya istenen bir durum olmayabilir) bir `DataExporter` yapamazsınız.

\n\n

İkinci Felsefe: Protokol Uygulaması Olarak ABC'ler (Yapısal Tipleme)

\n\n

İkinci, daha "Pythonik" felsefe, ördek tiplemeyle uyumludur. Bu yaklaşım, uyumluluğun ad veya mirasla değil, yapı ve davranışla belirlendiği yapısal tipleme'yi kullanır. Eğer bir nesne, işi yapmak için gerekli yöntemlere ve niteliklere sahipse, bildirilmiş sınıf hiyerarşisine bakılmaksızın, o iş için doğru tür olarak kabul edilir.

\n\n

Yüzme yeteneğini düşünün. Bir yüzücü olarak kabul edilmek için bir sertifikaya veya bir "Yüzücü" soy ağacının parçası olmaya ihtiyacınız yoktur. Eğer boğulmadan su içinde kendinizi ileriye doğru itebiliyorsanız, yapısal olarak bir yüzücüsünüzdür. Bir insan, bir köpek ve bir ördek hepsi yüzücü olabilir.

\n\n

ABC'ler bu kavramı resmileştirmek için kullanılabilir. Kalıtımı zorlamak yerine, gerekli protokolü uyguluyorlarsa diğer sınıfları sanal alt sınıfları olarak tanıyan bir ABC tanımlayabiliriz. Bu, özel bir sihirli yöntem aracılığıyla elde edilir: `__subclasshook__`.

\n\n

`isinstance(obj, MyABC)` veya `issubclass(SomeClass, MyABC)`'i çağırdığınızda, Python önce açık kalıtımı kontrol eder. Bu başarısız olursa, `MyABC`'nin bir `__subclasshook__` yöntemine sahip olup olmadığını kontrol eder. Eğer varsa, Python onu çağırır ve "Hey, bu sınıfı kendi alt sınıfın olarak görüyor musun?" diye sorar. Bu, ABC'nin üyelik kriterlerini yapıya dayalı olarak tanımlamasına olanak tanır.

\n\n

Örnek: Bir `Serializable` Protokolü

\n\n

Sözlüğe seri hale getirilebilen nesneler için bir protokol tanımlayalım. Sistemimizdeki her seri hale getirilebilir nesneyi ortak bir temel sınıftan kalıtım almaya zorlamak istemiyoruz. Bunlar veritabanı modelleri, veri transfer nesneleri veya basit konteynerler olabilir.

\n\n

import abc\n\n
class Serializable(abc.ABC):\n
    @abc.abstractmethod\n
    def to_dict(self) -> dict:\n
        pass\n\n
    @classmethod\n
    def __subclasshook__(cls, C):\n
        if cls is Serializable:\n
            # C'nin yöntem çözüm sırasının içinde 'to_dict' olup olmadığını kontrol edin\n
            if any("to_dict" in B.__dict__ for B in C.__mro__):\n
                return True\n
        return NotImplemented\n

\n\n

Şimdi bazı sınıflar oluşturalım. Önemlisi, hiçbiri `Serializable`'dan kalıtım almayacak.

\n\n

class User:\n
    def __init__(self, name: str, email: str):\n
        self.name = name\n
        self.email = email\n\n
    def to_dict(self) -> dict:\n
        return {"name": self.name, "email": self.email}\n\n
class Product:\n
    def __init__(self, sku: str, price: float):\n
        self.sku = sku\n
        self.price = price\n\n
    # Bu sınıf protokole uymuyor\n
class Configuration:\n
    def __init__(self, setting: str):\n
        self.setting = setting\n

\n\n

Onları protokolümüze göre kontrol edelim:

\n\n

print(f"Is User serializable? {isinstance(User('Test', 't@t.com'), Serializable)}")\n
print(f"Is Product serializable? {isinstance(Product('T-1000', 99.99), Serializable)}")\n
print(f"Is Configuration serializable? {isinstance(Configuration('ON'), Serializable)}")\n\n
# Çıktı:\n
# Is User serializable? True\n
# Is Product serializable? False <- Bekle, neden? Hadi bunu düzeltelim.\n
# Is Configuration serializable? False\n

\n\n

Ah, ilginç bir hata! `Product` sınıfımızın `to_dict` yöntemi yok. Hadi ekleyelim.

\n\n

class Product:\n
    def __init__(self, sku: str, price: float):\n
        self.sku = sku\n
        self.price = price\n
    def to_dict(self) -> dict: # Yöntemi ekleme\n
        return {"sku": self.sku, "price": self.price}\n\n
print(f"Is Product now serializable? {isinstance(Product('T-1000', 99.99), Serializable)}")\n
# Çıktı:\n
# Is Product now serializable? True\n

\n\n

`User` ve `Product` ortak bir üst sınıfa (object dışında) sahip olmasalar bile, sistemimiz onları `Serializable` olarak ele alabilir çünkü protokolü yerine getiriyorlar. Bu, bağlamayı çözmek için inanılmaz derecede güçlüdür.

\n\n

Protokol Yaklaşımının Artıları ve Eksileri

\n\n

Artıları:

Maksimum Esneklik: Son derece gevşek bağlanmayı teşvik eder. Bileşenler sadece davranışla ilgilenir, uygulama soy ağacıyla değil.
Uyarlanabilirlik: Mevcut kodu, özellikle üçüncü taraf kütüphanelerden gelenleri, orijinal kodu değiştirmeden sisteminizin arayüzlerine uydurmak için mükemmeldir.
Bileşimi Teşvik Eder: Nesnelerin derin, katı kalıtım ağaçları yerine bağımsız yeteneklerden oluşturulduğu bir tasarım stilini teşvik eder.

\n\n

Eksileri:

Örtük Sözleşme: Bir sınıf ile uyguladığı bir protokol arasındaki ilişki, sınıf tanımından hemen anlaşılmaz. Bir geliştiricinin, bir `User` nesnesinin neden `Serializable` olarak ele alındığını anlamak için kod tabanında arama yapması gerekebilir.
Çalışma Zamanı Yükü: `isinstance` kontrolü, `__subclasshook__`'u çağırması ve sınıfın yöntemleri üzerinde kontrol yapması gerektiği için daha yavaş olabilir.
Karmaşıklık Potansiyeli: Protokol birden fazla yöntem, argüman veya dönüş türü içeriyorsa, `__subclasshook__` içindeki mantık oldukça karmaşık hale gelebilir.

\n\n

Modern Sentez: `typing.Protocol` ve Statik Analiz

\n\n

Python'ın büyük ölçekli sistemlerde kullanımı arttıkça, daha iyi statik analiz arzusu da arttı. `__subclasshook__` yaklaşımı güçlüdür ancak tamamen bir çalışma zamanı mekanizmasıdır. Kodu çalıştırmadan *önce* yapısal tiplemenin faydalarını elde edebilseydik ne olurdu?

\n\n

Bu, PEP 544'te `typing.Protocol`'ün tanıtılmasına yol açtı. Mypy, Pyright veya PyCharm'ın denetleyicisi gibi statik tür denetleyicileri için öncelikli olarak tasarlanmış protokolleri tanımlamanın standart ve zarif bir yolunu sunar.

\n\n

Bir `Protocol` sınıfı, `__subclasshook__` örneğimize benzer şekilde çalışır ancak kalıpsal kod olmadan. Sadece yöntemleri ve imzalarını tanımlarsınız. Eşleşen yöntemlere ve imzalara sahip herhangi bir sınıf, statik tür denetleyicisi tarafından yapısal olarak uyumlu kabul edilecektir.

\n\n

Örnek: Bir `Quacker` Protokolü

\n\n

Klasik ördek tipleme örneğini modern araçlarla tekrar gözden geçirelim.

from typing import Protocol\n\n
class Quacker(Protocol):\n
    def quack(self, volume: int) -> str:\n
        """Vakvak sesi çıkarır."""\n
        ... # Not: Bir protokol yönteminin gövdesi gerekli değildir\n\n
class Duck:\n
    def quack(self, volume: int) -> str:\n
        return f"QUACK! (at volume {volume})"\n\n
class Dog:\n
    def bark(self, volume: int) -> str:\n
        return f"WOOF! (at volume {volume})"\n\n
def make_sound(animal: Quacker):\n
    print(animal.quack(10))\n\n
make_sound(Duck()) # Statik analiz geçer\n
make_sound(Dog()) # Statik analiz başarısız olur!\n

\n\n
Bu kodu Mypy gibi bir tür denetleyici aracılığıyla çalıştırırsanız, `make_sound(Dog())` satırını bir hatayla işaretleyecektir: `Argument 1 to "make_sound" has incompatible type "Dog"; expected "Quacker"`. Tür denetleyici, `Dog`'un `quack` yöntemine sahip olmadığı için `Quacker` protokolünü yerine getirmediğini anlar. Bu, kod yürütülmeden önce hatayı yakalar.
\n\n
`@runtime_checkable` ile Çalışma Zamanı Protokolleri
\n\n
Varsayılan olarak, `typing.Protocol` yalnızca statik analiz içindir. Çalışma zamanı `isinstance` kontrolünde kullanmaya çalışırsanız, bir hata alırsınız.
\n\n
# isinstance(Duck(), Quacker) # -> TypeError: Protocol 'Quacker' cannot be instantiated
\n\n
Ancak, statik analiz ve çalışma zamanı davranışı arasındaki boşluğu `@runtime_checkable` dekoratörü ile kapatabilirsiniz. Bu, temelde Python'a `__subclasshook__` mantığını sizin için otomatik olarak oluşturmasını söyler.
\n\n
from typing import Protocol, runtime_checkable\n\n
@runtime_checkable\n
class Quacker(Protocol):\n
def quack(self, volume: int) -> str: ...\n\n
class Duck:\n
def quack(self, volume: int) -> str: return "..."\n\n
print(f"Is Duck an instance of Quacker? {isinstance(Duck(), Quacker)}")\n\n
# Çıktı:\n
# Is Duck an instance of Quacker? True\n
\n\n
Bu size her iki dünyanın da en iyisini sunar: statik analiz için temiz, bildirimsel protokol tanımları ve gerektiğinde çalışma zamanı doğrulama seçeneği. Ancak, protokoller üzerindeki çalışma zamanı kontrollerinin standart `isinstance` çağrılarından daha yavaş olduğunu unutmayın, bu nedenle dikkatli kullanılmaları gerekir.
\n\n
Pratik Karar Verme: Küresel Bir Geliştirici Rehberi
\n\n
Peki, hangi yaklaşımı seçmelisiniz? Cevap tamamen özel kullanım durumunuza bağlıdır. İşte uluslararası yazılım projelerindeki yaygın senaryolara dayalı pratik bir rehber.
\n\n
Senaryo 1: Küresel Bir SaaS Ürünü İçin Eklenti Mimarisi Oluşturma
\n
Tüm dünyadaki birinci taraf ve üçüncü taraf geliştiriciler tarafından genişletilecek bir sistem (örneğin, bir e-ticaret platformu, bir CMS) tasarlıyorsunuz. Bu eklentilerin temel uygulamanızla derinlemesine entegre olması gerekiyor.
\n
\n
Öneri: Resmi Arayüz (Nominal `abc.ABC`).
\n
Gerekçe: Açıklık, istikrar ve belirginlik çok önemlidir. Eklenti geliştiricilerinin `BasePlugin` ABC'nizden kalıtım alarak bilinçli olarak dahil olması gereken tartışılmaz bir sözleşmeye ihtiyacınız var. Bu, API'nizi belirsiz hale getirir. Ayrıca, temel sınıfta temel yardımcı yöntemler (örneğin, günlükleme, yapılandırmaya erişim, uluslararasılaştırma için) sağlayabilirsiniz, bu da geliştirici ekosisteminiz için büyük bir faydadır.
\n
\n\n
Senaryo 2: Birden Çok, İlişkisiz API'den Finansal Verileri İşleme
\n
Fintek uygulamanızın çeşitli küresel ödeme ağ geçitlerinden işlem verilerini tüketmesi gerekiyor: Stripe, PayPal, Adyen ve belki Latin Amerika'da Mercado Pago gibi bölgesel bir sağlayıcı. SDK'ları tarafından döndürülen nesneler tamamen kontrolünüz dışındadır.
\n
\n
Öneri: Protokol (`typing.Protocol`).
\n
Gerekçe: Bu üçüncü taraf SDK'ların kaynak kodunu, onları `Transaction` temel sınıfınızdan kalıtım almaya zorlamak için değiştiremezsiniz. Ancak, her bir işlem nesnesinin, adları biraz farklı olsa bile, `get_id()`, `get_amount()` ve `get_currency()` gibi yöntemlere sahip olduğunu biliyorsunuz. Birleşik bir görünüm oluşturmak için `TransactionProtocol` ile birlikte Adaptör desenini kullanabilirsiniz. Bir protokol, ihtiyacınız olan verinin *şeklini* tanımlamanıza olanak tanır ve böylece protokolü karşılayabildiği sürece herhangi bir veri kaynağıyla çalışan işleme mantığı yazmanızı sağlar.
\n
\n\n
Senaryo 3: Büyük, Monolitik Bir Eski Uygulamanın Yeniden Düzenlenmesi
\n
Eski bir monolit'i modern mikro hizmetlere ayırma göreviniz var. Mevcut kod tabanı karmaşık bir bağımlılık ağıdır ve her şeyi bir kerede yeniden yazmadan net sınırlar getirmeniz gerekiyor.
\n
\n
Öneri: Bir karışım, ancak Protokollere büyük ölçüde yaslanın.
\n
Gerekçe: Protokoller, kademeli yeniden düzenleme için olağanüstü bir araçtır. Yeni hizmetler arasındaki ideal arayüzleri `typing.Protocol` kullanarak tanımlayarak başlayabilirsiniz. Daha sonra, monolith'in bölümleri için bu protokollere uyması için adaptörler yazabilirsiniz, mevcut eski kodu hemen değiştirmeden. Bu, bileşenleri kademeli olarak ayırmanıza olanak tanır. Bir bileşen tamamen ayrıldığında ve sadece protokol aracılığıyla iletişim kurduğunda, kendi hizmetine çıkarılmaya hazırdır. Resmi ABC'ler daha sonra yeni, temiz hizmetlerdeki temel modelleri tanımlamak için kullanılabilir.
\n
\n\n
Sonuç: Soyutlamayı Kodunuza Dokumak
\n\n
Python'ın Soyut Temel Sınıfları, dilin pragmatik tasarımının bir kanıtıdır. Hem geleneksel nesne yönelimli programlamanın yapılandırılmış disiplinini hem de ördek tiplemesinin dinamik esnekliğini göz önünde bulunduran sofistike bir soyutlama araç seti sunarlar.
\n\n
Örtük bir anlaşmadan resmi bir sözleşmeye yolculuk, olgunlaşan bir kod tabanının işaretidir. ABC'lerin iki felsefesini anlayarak, daha temiz, daha sürdürülebilir ve yüksek oranda ölçeklenebilir uygulamalara yol açan bilinçli mimari kararlar verebilirsiniz.
\n\n
Temel çıkarımları özetlemek gerekirse:
\n
\n
Resmi Arayüz Tasarımı (Nominal Tipleme): Açık, belirsiz ve keşfedilebilir bir sözleşmeye ihtiyacınız olduğunda doğrudan kalıtım ile `abc.ABC` kullanın. Bu, çerçeveler, eklenti sistemleri ve sınıf hiyerarşisini kontrol ettiğiniz durumlar için idealdir. Bu, bir sınıfın bildirimle ne olduğu ile ilgilidir.
\n
Protokol Uygulaması (Yapısal Tipleme): Esnekliğe, bağlamayı çözmeye ve mevcut kodu uyarlayabilme yeteneğine ihtiyacınız olduğunda `typing.Protocol` kullanın. Bu, harici kütüphanelerle çalışmak, eski sistemleri yeniden düzenlemek ve davranışsal polimorfizm için tasarım yapmak için mükemmeldir. Bu, bir sınıfın yapısıyla ne yapabileceği ile ilgilidir.
\n
\n\n
Bir arayüz ve bir protokol arasındaki seçim sadece teknik bir detay değildir; yazılımınızın nasıl gelişeceğini şekillendirecek temel bir tasarım kararıdır. Her ikisinde de uzmanlaşarak, sadece güçlü ve verimli değil, aynı zamanda değişikliklere karşı zarif ve esnek Python kodu yazmak için kendinizi donatırsınız.